Encryption, or the process of converting ordinary information (“plaintext”) into something unintelligible (“ciphertext”), has been used for centuries to allow a user/sender/author to convey sensitive or confidential information to other parties so that such information, if intercepted by another who is not intended to receive or to read the information, is unintelligible to the unintended recipient. The encrypted information, data or content, once received by the intended parties, must be decrypted in order for the intended parties to understand the information. Decryption is the reverse from encryption and is the process of moving the encrypted information from the unintelligible ciphertext back to plaintext.
Cryptography has been important over the years but maybe never more critical than in this modern era of electronic communication. For example, in the present day, people work and operate in an environment of sending and receiving much information—in the form of, e.g., emails, text messages, instant messages, blogs or other web communications. It is not unusual for a worker to rarely pick up a pen or pencil as much work is done online. Further, the speeds and bandwidths available today allow for many electronic files to be easily sent or transferred from a sender to one or more intended recipients. This has made industry much more efficient.
However, there is an increased risk that an electronic file will be intercepted by an unintended recipient. Due to the proliferation of wireless communications, this risk has increased in recent years.
The inadvertent disclosure of data can pose a serious issue such as by exposing a company's trade secrets or other confidential information to a party who may use it to the company's disadvantage. As such, many times, a sender will choose to encrypt the content prior to sending.
Encryption forms and levels vary in forms of complexity as well as ease of use. For instance, an electronic file (e.g., such as a word processing document) may be encrypted by the author utilizing the application's (e.g., work processing application) encryption mechanism. By way of example, in a most basic form, an author may password protect an electronic file (the password being used as the cipher to the encrypted file, the application having an encryption algorithm to transform the plaintext into ciphertext), send the encrypted file, and convey the password to the recipients by way of a separate manner—such as by telephone or a separate email. The recipients then, when opening the file and being challenged for the password may use the password to open the encrypted file. This is well-known as are other forms of cryptography such as symmetric key cryptography and public key (Diffie-Hellman or asymmetric key) cryptography.
There are many levels of encryption. For instance, a database can be encrypted, a file or document can be encrypted as noted above, or a field can be encrypted.
The most popular level of information to encrypt is e-mail as it is most prolific form of electronic communication. For many people, e-mail is often a substitute for a real conversation. Therefore, similar to the real world where one can shut the door and have a private conversation, e-mail correspondence needs the same capability. To accommodate this need, many email clients provide the ability to encrypt mail before a user sends it, after the user receives it, or before the user saves it. One example of a very popular and highly successful email client is IBM's Lotus® Notes® client which works in conjunction with IBM's Lotus® Domino server software. A description of Lotus Notes and Lotus Domino can be found here:    http://www-142.ibm.com/sofrware.sw-lotus/products/product4.nsf/wdocs/noteshomepage?OpenDocument&ewesite=notes
Email client software is installed on a client computer 520, seen in FIG. 5, and works in conjunction with server software installed on the server shown as numeral 540 in the FIG. 5. In the basic installation, the client computer 520 communicates with server 540 as well as other computers 534, 534A, 534B 534C.
An email client may use a form of the public key encryption noted above. For mail encryption, a user encrypts a mail message before he/she sends the message, Notes uses the recipient's public key to transform the plaintext of the message body to ciphertext. Once received, the recipient's private key decrypts the message. The private key is part of the user's ID file. Therefore, without the right ID file, the message body looks like gibberish. Of course, messages aren't safe if that ID file is lost or stolen; however, if the ID owner has applied a password (one that is difficult to guess, such as a string of random alpha-numeric characters) to his ID file, encrypted messages remain safe.
An example of the UI which allows a user to make such selections is shown in FIG. 1 where a user can encrypt mail before he sends it through a manual option, or automatically by selecting the encryption setting in his user preferences. To use the manual setting:    1. The user opens the message he wants to send in edit mode;    2. The user chooses Actions-Delivery Options (the pictorial shown as 100 in FIG. 1);    3. The user selects the Encrypt option 102; and    4. The user then clicks OK 104.
The message is encrypted using the encryption algorithm of the email client. This option applies to the current message; future messages are not encrypted unless this delivery option is selected. If, however, the user wishes all outgoing messages encrypted automatically, and the email client allows that option, the user makes the following user preference selection as shown in FIG. 2:    1. Choose File-Tools-User Preferences.    2. Select Mail in the User Preferences dialog box shown in the UI screen 200    3. Select Encrypt sent mail 202.    4. Click OK 204.
Once this option is set, the email client encrypts all outgoing messages. If the recipient's public key is not available, which is often the case for Internet mail, a warning message may appear. This message allows the user to continue sending this message or cancel it.
Incoming messages may also be encrypted. For instance, in Lotus Notes, this option is found in the user's Person document in the Public Address Book. To encrypt all incoming mail, a user performs the following steps (as shown in FIG. 3):    1. Open the Public Address Book.    2. Open the user's Person document 300    3. Click the Edit person button.    4. In the “Encrypt incoming mail” field 302, select Yes.
Enabling this option automatically encrypts all received mail with the user's public key. Decryption relies on the user's private key, which is part of the user ID file.
The previous description provides some background to the email encryption/decryption process in an email system. One of the problems of the present day encryption systems, however, is that only the listed recipients are able to decrypt the email message or calendar invitation. This is a problem as it is often the case that the author wants the data to be readable by additional parties. The most typical case of this is to allow an executive's administrative assistant or the recipient's manager to also read the encrypted data.
The state of the art is cumbersome. Presently, if a user wishes, for example, to send e-mail or a calendar meeting document to someone and make it available to his or her assistant or manager, the user needs to first identify who his or her assistant or manager is (typically by searching a user interface for a directory) and then enter the assistant's or manager's name as an e-mail recipient to allow them to read the mail. This is wasted effort to locate the name. It is also unnecessary for the assistant or manager to actually receive the e-mail in his or her own mailbox because the assistant or manager many times reads the mail directly out of the executive's mailbox.
An alternative approach is for the assistant or manager to use the principal's/executive's credentials, i.e, use his or her password. This behavior is prohibited by many organizations for numerous security reasons. For instance, it allows the assistant or manager to impersonate the principal in sending emails as well as in signing the communications. Additionally, it may allow the administrative assistant or manager to read documents he or she is not authorized to read. That is, it doesn't give the author/sender control allowing some messages to be read by the assistant or manager and others to be protected from the assistant or manager.
Another alternative approach, which allows the assistant to read incoming messages without allowing the assistant to send outgoing messages under the premise that it is from the principal, is for the assistant and the principal to share an encryption public/private key but not to share a signing public/private key. This is only available in some software systems (most systems combining the encryption and signing credentials into a single credential). This solves the impersonation problem but still does not solve the granularity problem. That is, it doesn't give the author/sender control allowing some messages to be read by the assistant, some messages to be edited and replied to by the assistant while others to be protected from the assistant.
In view of the foregoing, a need exists to overcome these problems by providing a system and method for an end user to encrypt an email or other data and send that communication to a recipient, and to choose specific people and/or roles who should be able to read the content in the email or communication.